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I. EXECUTIVE SUMMARY 

- The mission and assumptions granted in the charter did not require signifieant 
modification. 

- A 'common operating system' is possible. 

- A 'common operating system' is necessary as the glue to sustaining an 
integrated product line in the eyes of the user. 

A common software set is necessary to achieve a total savings on a joint 
effort, i.e. development costs will not be reduced, only focused; support 
costs are reduced only If the product line is Integrated with common software. 

- A single (joint) development is feasible and desirable. The product, however, 
would not be a single or common operating system but rather a cohesive 
'construction kit' for several versions of the operating system. 

- The kit would allow us to produce versions v/hich were optimized for space, 
or performance in different operational environments, such as batch, 
interactive, and transaction. But below a cutoff point and above a defined 
size the probability of successfully using a single set of modules was judged 
to be slight. 

- The Operoting System, In order io span the range with one set of modules 
must have a consistent functional architecture for all models of the line. 
The architecture was defined, 

- The Operating Systemwas sub-divided Into twelve functional components 
for detailed analysis: 
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- Task Monagcmenf 

- Job Management 

- Memory Management 

- Job Control Language Processor 

- Device Drivers 

- Pvecorcl I/O 

- Block I/O 

- Scheduling and Allocation 
r.. Binding 

- Device Allocation 

- Operator Control 

- Data Management 

- Each component investigated appeared to have the same functional and philosophical 
characteristics from both companies' points of view* 

- Most components appeared to require parameterization or different versions 
in-order to serve In the target range of configurations or for different cporalional 
environments. Device drivers v/ere an exception; they appeared to be 
independent of the preceding variables, 

- The cost effective use of the 6150 for the "PPU" changes the O.S. approach 
. from that used in the CYBER 70 to an approach requiring more sophisticated 

memory management and multi-tasking, 

- A Concopi of locally public memory was di^scrlbed. 

- Scheduling and allocation of resources is the primary component affected by 
changes of scale and operational environments. 
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- Appendices showing present" SCOPE 3.4 distribution of componenfs was 
attached at the request of the JAC. The 0,S, Task Force also voted 
on a probable distribution of components In the proposed Operating 
System, 
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jl. RECOMMENDATIONS 
A. Success Criteria 

There are four major issues which the Operating System Task Force 
recognized as critical in being able to state that a common operating system is a 
recommended venture. 

T • Agreement had to be reached that there v/as a commonality in 
functional requirements for operating over the range. 

2. We had to recognize the possibility of at least one possible strucvure 
•of an operating system to cover the range. 

3. There hod to be general agreement that a peripheral processor based 
operating system was feasible and desirable for the entire range. 

4. We had to be convinced that no technology break throughs would be 
required to produce a common operating system to cover the joint 
product line. 

The Operating System Task Force believes that those criteria have been 
met cs evidenced by ihe following conclusions and recommendations. 
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B. Summary Conclusions and Strategy for a Common Operating System 
The Operating Systems Task Group believes that the most important concept which must 
be understood by any reader of this report is that we do not believe that a "Common 
Operating System" or a "Single Operating System spanning the full range" is attainable. 
We do however believe that a joint development effort is feasible and desirable which 
would produce what we shall call an Operating System Construction KiL 

The group applied the majority of its energy to comparing their experience and preconceived 
ideas regarding functional features and design concepts of an operating system for the range 
of configuraHons under study.. This was done wifh the goal of arriving at a measure of 
the feasibility of an "Oper.atirig System Construction Kit" with .significantly greater 
confidence than could be attached to the feasibility of a "Common Operating System" 
as suggested by the JAC in their report, to the Steering Committeeo An "Operating 
System Construction Kit" was understood to be a set of modules, defined and implemented 
such that^ although redundant versions of some modules may be required to soon the 
range, the interfaces to those modules are processor inde^pendent and consister.t \c live 
extent that to replace one modulo v/ith another version of that module would nec-BSi^iiaie 
no redesign or reprogramming of the remaining modules. Further it is raccgnized ihal nor oil 
modules need reside in the peripheral processors. Some modules may, in fact, be CPU 
modules. We arrived at the conclusion that such a "Construction Kit" is feasible from a 
256K bytes, single processor (6150) system through a system containing a single P2 central 
processor, four 6150 peripheral processors, and 8M bytes of memory to a system composed 
of multiple P3 central processor, twelve 6150 peripheral processors with 32M bytes of 
shared memory. 
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This conclusion Is based on our assumption thaf a satisfacfory and consistent virtual 
storage strategy can be attained (See Virtual Storage Task Group Report). 

It IS recognized that the above range of configurations does not cover the full range of 
configurations defined in the table of Integrated Product Line System Modules prepared 
by the Strategy Task Group (See Appendix C). The Operating System Task Group 
believes there is a significant risk associated with assuming that we can utilize coivn\on 
modules end interfaces as wellas retaining a consistent operoflng system. structure and 
architecture above and below the indicated range. 

An "Operating System Construction Kit" as defined above, would, from our customer's 
point of view, appear to be a set of versions of an operating system for an integrated 
product line. This is due to the fact that we, the manufacturers, would configure 
several versions (three to six) from the "set of modules" which together would cover 
the range of configuralions and cperaiional environments under consUaro'-jon. However 
not only could a customer move an cpplication which lie had daveloped from cno version !o 
another with no difficulty, but itwould indeed be true that many modules appearing in 
one version would appear in one or more other versions, and further than that the 
inter-module interfaces would be consistent across all of the versions. 

It Is in fact the tightly disciplined control of inter-module interfaces which is the 
heart of our understanding of what needs to be accomplished in order to say an 
"Operating System Construction Kit" has been realized across the range of products. 
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For example, suppose fhat when the developmenf is complete and the dust has cleared, 
every module in the set appears In two versions and furthermore that when we configure 
the various operating system versions we discover that some of themconfain only the 
"A" versions of modules and the others contain only "B" versions of modules. We would 
still argue that v/e had attained our goal of producing an "Operating System Construction 
Kit" if the inter-module interfacing v/as such that a version of a given module could 
be replaced with the other version of that module. 

The interchangeability of modules is the pivotal issue with regard to the attainment of 
on "Operating System Construction Kit." It is of the utmost importance, not^only to 
qttain.the necessarydegree of .configurabili but more importantly it is necessary in 
order that the unit testing of modules can minimize the system integration, system 
generation (build), system test, field configuration and field installation costs and 
schedules. 

A clear understanding of ihis issue focusses our attention on the sirtgle mo:;t cri;^) :cii 
elemant of risk. The degree to which we realize this goal of Intercnangv^cbiliry of 
modules will determine the degree to which v/e succeed in our endeavor. Further?nore, 
the realization of an adequate level of success will require ovvell conceived and 
implemented set of tools, practices and procedures, and administrative controls . . . 
in short a comprehensive "software engineering discipline" which is understood,, 
accepted, and enthusiastically supported by management and development personnel. 
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The Operating System Task Group believes that qn adequate level of success in these 
areas can be attained, they do not believe that it will be easy, but they agree that 
it is necessary/ Furthermore, we believe that quite independent of any joint 
development activity, each company must pursue vigorously the area of technology 
necessary to produce an "Operating System Construction Kit'^« 

The technology of 'Operating System Construction KitsV has evolved since the middle 

1960*s v/ith the Introduction of OS/360, Today both NCR and CDC use System 

Build or System Generation techniques v/hlch allow parcmeterizalion of v/el! 

defined functional modules. Additionally, recent developments in the industry 

include table driven techniques and syntax driven mechanisms. However, the use 

of replaceable modules in the Operating System Construction Kit creates interdependencies 

that compound the interface and testing problems. The additional idovelopment 

complexity and cost, however, are expected to remain within reasonable limits. 

In other words, the requirement to span the full range increases the magnitude 

of the problem appreciably but does not require "o technology break through. Further, 

parallel advancemanf in sofh.voTe v/riter's languages and sofrv/ore engineering 

techniques oid in the odvanccment of configuration independenr Operating S/stern 

Construction Kit technology. 
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C. Recommended Actions 

The Operating System Task Group recommends five specific activities 
which should be initiated as quickly as possible: 

!• Obtain full corporafe commitment by both companies to the joint 
development of the Operating System Construction Kit as defined. 
This assumes that in one way or anoiher a single organization is established 
and given the responsibility for thai* development. 

2. Since the software engineering tools and procedures are critical to 
ensure success, the specification of a total software engineering 
system must be Initiated, 

3. A clearly delineated statement of requirements and goals for the 
Joint Product Line must be^ 

2 above can proceed in parallel for perhaps as much as six months 
preceeding such a statement. 

4. An integrated product line has been expressed as a multi^-dimcnsional 
opportunity. Th.e basic dimensions are 1) direct cost saving through 
shared development, production and support, and 2) a broad produci 
offering in the eyes of the user. The first point does not require an 
"Integrated product line'* but rather only the sharing of some coniponents. 
Further, It is the belief of the Operating Syston? Toik Force that g 
certain critical mass of commonality must be achieved In order to-J 
successfully achieve and maintain a trUely integrated product line. 

A common set of operating system versions is the least amount of 
commontility to sustain an integrated product line and is in fact 
fundamental to any other "oxternar or software commonality. 
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5, We further recommend that any joint venture must go beyond an 

agreement to implement operating systems to common specifications. 
Any such agreement would be untenable due to the many conflicting 
pressures in each company. As a result, during the varying stages 
and at various levels of the development process commonality would be 
lost to the extent that its value would be neglible. 



OPERATING SYSTEM TASK FORCE 11 

111. MISSION AND ASSUMPTIONS 
A. Mission 

The main mission was consideration of the full opportunity of cooperation. 
There may well be other levels of cooperation in the area of operating systems^ 
however, the operating system task group did not give explicit consideration to 
them but rather assumed this was to be a consideration of the Strategy. Task Group. 
The mission was described then as: 

Propose and define method(s) for achieving the following goal: 
A single set of modules v/hich can be used to construct general 
purpose opera Hng systems for configurctions spanning from the top of 
the standard product line down to a minimum. 
The proposal should quantify fhe degree of antic 

dimensions: 

1) Range of configurations; 

2) Range of features (subsettability); 

3) Range of'O.S. type emphasis (e.g. time sharing, remoio bcAcU, 
transaction processing. 
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B. Assumpfions 

The logical or virtual architecture is consistent for all models of fhe 
joint product line. 

The minimum member of the joint product line for this 0,S. will consist of: 
single processing element, 256K bytes, lOOM bytes RAS, keyboard and CI>J 
operators console, plus peripherals. 

- A large system Is assumed to be 

• >> 2 CPU's \vith option for their ov/n private executable rnemory 
MOPPU's 

> lOOM bytes main memory 
^3 block access storage devices plus a large variety of peripherals 

■ - Multiple systems are to be considered and consist of some combination, 
of large systems which are coupled via dynamically shared peripherals 
and block access storage devices. Each system executes its ov/r: copy 
of the operating sysiom. 

Nefv/ork systems are considered to be muliiple ty^fems which ore 
linked but do not share peripherals and block access storage devices. 

- The O.S. will reside primarily in the PPU's. 

- Same data formats across all processing elements of the P. L. 
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. - All modules of the O.S, can be written in one software writers 
language which will be defined by that task force. 

Memory will be managed by the O.S. with a consistent virtual memory 
scheme. 

Permanently available systems disk. 

- V.M-. and co-resident virtual machine proposal v/illbe devsloped 
by other task forces. 

- There is no particular requirement to support old devices or file foi'mats 
in the new O.S. except as required for co-resident virtual machines. 

Hardware modifications generated by this task force can be included in 
the system design. 
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G. Critical Issues 

General strategy for a specific tasking structure for CPU- PPU - 
memory resource allocation including multiprocessing/ scheduling, 
dispatching, etc, 

- General strategy for O.S. levels of features and services for a range 
of configurations. 

- General strategy for 0,S. levels of capability to perform tiniesharing, 
remote batch, transaction services, etc. 

- General strategy for O.S. construction to satisfy modularity, flexibility, 
configuration independence, optimization of performance, linkage 
mechanisms, and control methodology. 

Other Issues: 

- Reliability, avaiiobilii-y, serviceability consideration. 

•- Human factors 

> Performance 

FPU logicol structure 

P-languoge 

Identificution of critical performance issues. 

- Effect of virtual memory on O.S. and FPU's. 
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EsUmdte fhe number of FPU's required in the minimum configuration 
(virtual). 

- Any special considerations for project control . 

Recommended service functions (e.g. measurements, modeling, system 
integration, regression tests). 
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IV. CONSIDERATIONS OF ENVIRONMENT AND SCALE 
A. Operational Environments 

Six modes of access (operational environments) to the system (batch, remote batch, 
interactive, transaction, real-time and time-critical) have been considered. Those 
six have been reduced to three primary distinct modes of access. Remote batch and 
batch are considered to be the some. Some feal-ures required for time-critical applications 
will be included in the operating system but general support for these opplicafions were 
not included In our discussions. because these applications generally require -sp .:cianzaficr; 
of the operation system for each applicaticn. Real-time and Interactive reqjjirements 
are sirniior and wi!l be provided as capabilities in the operating system (reci-nrne with 

small intervals will creai-e problems). Therefore, three mpdes of access to tlie system were 
considered in this report. They are batch, interactive and transaction. 

Scheduling and allocation appear to be the major differences in the operating 
system duo to the three modes. The intent of the allocation and scheduling 
algorithms differ in different operating environments. Response time is the important 
objective in Interactive systems, total fhroughpuf for batch systems and \:\ lr':-r;.acrion 
sysiems, the objaclive is to maximize throughput yer provide "reasonc^b: .' i ^: orise ilino. 
Each of these objectives can be achieved prlmcrily through the schec:!^..; :. . oJlocCi-ion 
c!goril"hm5. Combinations of operctional envlrcnmanl-s ore also depen:' -.] on scheduSi.iQ 
end ollocation inmseling cl^iecflvos. Co-exlstance of Hvc different modes of access h en 
issue of volume and scale. In the larger systems It" Is cleoi ihat oil ihree modes of access 
may co-exisf ai)d scheduling and allocation appear to be tlu? major problem for the 
cpeiating syslcin in that co-exhtance. 
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Differenf scheduling and allocaflon techniques and clgorifhms will be required for 
each of operational environments and for combinations of these o Additional techniques 
end algorithms will be required for various systems in the range (at least different 
algorithms will be required for the upper end and the lower end)V The effort required 
for different algorithms can be reduced by using table driven techniques. 
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B. Issues of Scale 

From the view point of the operating system, the Integrated Product Line 
must have a consistent functionally logical architecture. That architecture is 
described by the logical structure of the computing system which the operating 
system must support. From the assumptions described in Section 111, this logical 
structure is shown as follows: 
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One of the key questions then Is wliat is required to provide an operating 
system which supports such a brood configuration range? It has been assumed that 
it fs feasible to develop an operating system for the large general configuration. In 
considering the remainder of the range, memory has been identified as a key factor 
in the issue of scale. With shared memory sizes ranging from relatively small to 
extrem.ely large, differences center around various sfrciegies for oplimum use of 
that memory. On the low end memory is extremely cririca! and oprimizaticn 
centers around effective utilization of thai* memory. On the high end the 
optimization centers around effective CPU utilization. 

The task group has identified three potential techniques for minimizing resident 
memory requirements. 

Compaction - By t.he use of interpretive execution techniques code compaction 

could be derived for OS modules thus deriving a savings in shared memory 
requirements. The exact extent of the savings is somewhat controversial 
but could be Gs much as 4 fo 1 compaction. 

Performance Degradation ^Certain modules Vy'ould be more finely overloyec! -.r 

rnoved to non-resident storage. This would. reduce overall shored rne:nory 
requiremenis at the expense of decreased perfornHinco. 

Reduction of Feaiurcjs - Certain features of the operating system could be eliminated 
by removing certain modules of the operating system or replacing such 
modules with modules providing 6 reduction of capability. 
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It was agreed that the above techniques could be incorporated to yield an 
overall reduction of shared memory requirements to provide a significant lowering 
of the minimum shared memory requirement to 1/4M Bytes. However, by following 
the above implementation approach, additional complexities will be introduced in this 
area. The significance of this is related to the quality of the techniques developed 
during implemenforion to cope v/Ith the added complexify. 
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V. ANALYSIS OF O.S. FUNCTIONAL CAPABILITIES 
A. Definition of Key O.S, Modules 

In order to assess the feasibility of a single development of a set of modules 
which can be configured into various installation-specific operating systems to 
cover the range encompassed by the Joint Product Line, the set of modules was 
parliticned into twelve categories. The set of modules failing into a given category 
is called a 'componenP, The twelve components which vvere selected are briefly 
described belov/ and a section for each component Vr'hich discusses cur deliberations 
and observations follows. 
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Task Management 

Task Management is that collection of modules which provide services to 
tasks as entitles. These services include task creation, invocation and 
inter-fask communication primitives. 

Job Management 

Since "jobs" are arbitrary collections of tasks. Job Management is that 
collection of modules which provide operating system services v/hich deal with 
collections o f tasks which are designated by the user as a "job". These 
include job initiation, pre--al location .ofres^^^^^ 
termination. 

Memory Management 

That collection of modules which provide the operating systoni services 
reiofing to the allocotion, de~ci!locaiIon, gcrbcge co! lection (etc.) of rool 



Job Gontro! Language Processor 

That collection of modules which effects those actions specified by the user 
in a "JGL Task". Where a JGL Task is a task whose source form is Job 
Control Language. 
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Device Drivers 

Those device dependent modules which perform the functions associated with 
transferring a physical data records to/from an external device from/to memory. 

Record I/O 

Those modules which provide access'to user defined Iccjical reccrds/ 

Block I/O 

Those modules which provide the device dependent interface between Record 
l/O-and the Device Drivers, These include buffer management and device 
scheduling. 

Scheduling and Allocation 

Those module;, vyhich contain fhe decision-making sfrcitegies with rzo^Ard 
to the assignment of resources !o a collection of con'ipeting requosioi': jf 
such resources. 

Binding 

That collection of niodules which provide the Operating System services 
associated with resolving references among separately compiled program 
units. These services fall inio two major categories "static" and "dynamic" 
binding services. 
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Device Allocation 

Those modules which deal with the specific problems of allocating I/O 
devices as resources (see Scheduling and Allocation). 

Operator Control 

Those modules which provide the means by which an operator on\} the 
Operating System communicate with each other (see Job Conrroi 
Language and the Job Control .Language Processor). 

Data Management 

Those modules which provide the I/O and data structuring services above and 
beyond Record I/O, Block I/O and Device Drivers. 
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B. Analysis of Capabilities 

Task Management 
A task is the smallest unit of work recognized by the system. Thus, it is also 
the ultimate consumer of resources. It has two parts: the procedure which is never 
modified and the dynamic context which differs for different instances of execution 
and which may be modified. Task Management handles the creation of, tormination of, 
control of, and communication ampng the tasks in the system. 



Primitive Task Monoge menl- Funcrions 
© Task initiation 

ESTABLISH - creates an inactivetask 

CALL - creates a process referred to as the callee of the process that 

issued the CALL (the cal[er). 

o Tosk terminaHon 

DISESTABLISH - dcshoys on InGclive task 
CALLEND - terminales the issuing process. 

o Events 

WAIT - puts a process into wait state (flushing allof Its dynamic context 

to shared memory) until the occurrence of an event or set of 
events. Four types of events have been idenfified: 
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1. Alarm - a specified elapsed Hme or fime~of~day. 

2. Process termination - the destruction of a process after it has 
issued a CALLEND. 

3. Signal - an event caused by another process issuing a SIGNAL 
function. The process v/aiting for a signal has the option to 
"extinguish" the signal v/hen he is av/ckened by it (he will 
execute rnutuaily exclusive of other processes vyho i'pecifled 
"extinguish") oi to. leave the signal sei (lie v/ill execute 

• along with any other process v/aiting for thot sign^al). 

4. Process directed .wcikeup - The process has been specifically 
named by another process to be. awakened* 
SIGNAL —sets a named signal. If this is an event another process has 

selected (been waiting for), it will be made ready (awakened). 
If ihe signal has nol been selected, it wli! La *>avud ur: H o 
selecflosv is mado. If [he sigjiolis olreciciy z^d ^ {he sv; . :i,rr 
has the cpllon of having this sefflng dbi 'jtji rded or hcv/Incj if 
stacked behind the previous setting. 

© Intor-process parameter passing 

Along with the ESTABLISH, CALL, and SIGNAL functions, a process may pass 
some parameters. This may be either by name (shared segments) or by value 
(copied data from one process's address space to the other's). 
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EXEC Tables 



o Task lisf - is composed of task definifion blocks and process, control blocks. It 

appears that an abbreviated process control block of up to 200 bytes would 
be permanently resident in shared memory, showing such things as. 

linkages to other processed and current state. '' Other elements of the process 
control block such as the address spcce descriprlon (segment and page 
tables) could possibly be moved cul- to secondary storage if necessory. 



o Event lists - contain signals that have been set or selected and tlrnes-of-day 

that processes are waiting for, 

o Ready list - shows all processes that ore ready to execute on .©processor. This 

is the list searched by each processor when it needs something to do. 

Tasks are ihe basic mechanism for load leveling aero-: proc^v:isors. This ;:Jcd5 
tv/o forms: 

1. Load leveling across different types of processors is ro ba done by re-codiiig 

and/or re-compilation of a task (not procedure) for the desired type of 
processor. The interface befwe^^n tasks is strictly procosscr-independ;:nt; 
a task does not knov/ what kind of processor is used by the tasks that is 
communicates with. 

2. Load leveling across processors of the some type is to be done by maintaining 

all dynamic context of a process in shared memory whenever the process 
is not executing on a processor. 
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Switching fhe peripheral processor among processes can be done by firmware 
or software. Firmware switching may be faster but results in a significant loss of control 
over scheduling. Control over scheduling is important because of the wide variation with 
operational environment (see section on Scheduling and Allocation), Software switching 
is, therefore, preferred unless performance analyses shov/ significant degradation in totoJ 
system performance <i 

It is necessary for tasks to communicatSo This Is generally done through tv/o 
kinds of funcf-ions v/hich are sometimes combined: 

1. Event handling functions provide facilities to synchronize operations, 
2o Parameter passing functions provide facilities for passing data. 

Events can be. handled with any of three methods: 

1. Events trigger immediate scheduling cycle (Interrupt Driven). 

2. * Events set a flag in memory which must be tested later (Memory Driven), 

3. Events transmit data to a task, the data is quouod until transmission can 

occur (Message DrivenX 

Any hardware con f I gurarion end most soffwara S)^tems provide so;;:;-^ eloment:^ of 
oaeh mothod. Appropriate softvycre techniques will usually allow one avy^od to bo 
converted to another, ifnecessaiy. 

Processes are either ready or waiting. The state is usually represented by the process 
being in either a ready list or a waiting list. Event posting functions cause processes to be 
placed into the ready list. Event waiting functions cause processes to be placed into the 
waiting list. 
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Paramefers can be passed between processes either of two ways: 

1. Data IS placed into and removed from a segment shared by the communicating 
processes; In. this method the processes control the communication themselves, 

2, Data is moved from the address space of one process to that of the other. 
This facility must be provided by the system. 

Processes must initiate the execution of other processes^ control thcl; -3;:jcj;Ion and . 
recognize their termination. This allows a system structure where a system tc%k spcwns 
(creates under its control) {ob processors which spawn user processors, etc, (see ihe 
section on Job Management). 

Task structure is important in system structure. Because a task can run only 
on some real and virtual machines, tasks must be structured so that functions can be 
executed by the processors appropriate to it. It is desirable to be able to use 
different processors for the same task .without changing the structure. 

Task dynamic contexts and working sets can be easily identified if tasks correspond 
to source language (PASCAL) procedureSo This can greatly sin-pi rrycperGtingsyvrom 
implomentafiono 

Both peripheral processors and central procosscrs wili <:;xeculci rosk rnOii:i;-;:::n;^nL 
All task management dynamic data resides in shared memory vvh^.re it can be accessed by 
all processors. 

Effect of Varying Sl/e and Operating Fnviionment 

We believe that the basic architecture described above will be unaffected by 
large variations in the numbers of ttisks. We expect as many as 1000 processes in the 
I-4M byte range of systemt.. 
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This also does not seem to affect the architecture« There will be a problem in 
real-time environments with small time intervals since we expect a reasonably large 
task switch time (up to one mill iseconc). 
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JOB MANAGEMENT 

Job management here Is defined mcsrly by exclusion, it Is those mcdulr-v 
which are not JCL, I/O and data management, product set, applications, or 
task management. !t includes spooling of Input and output files, jcb scheduL' j^ 
end operating environment definition. 

We have Identified three modes of access to the system: Interactive, 
batch, and transaction. Transaction differs from Interactive In that it usually 
has shorter, more well-defined periods of activity. It appears to us that all 
three modes can co-exist in the same system by allowing suitably flexible scheduling 
algorithms, such as table-driven. Even though the implementation is probably non-trivial, 
it appears to be less a function of the wide range of scale we are talking about 
than the variation In appiicatic?! of any one size system. 
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A "|ob" is the external user of the system's idea of a piece of work. The operating 
system in general deals with tasl<s,wlth a job being an artlfically related collection of 
tasks for the convenience of the user. 

For example/ a Job might be considered to be all the tasks created as a result of 
the iten-^ between "Logon" and "Logoff" control items. There will probably be al least 
one "Operating System Jobo" There must be accounting information provided at o 
job lave!. 

The following diagram depicts the relationship among system, jobs, and tasks. 
All tasks which become active as a result of the Logon are part of a single [ob. 
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Note: For the purposes of this diagram a file is an asynchronous process which provides 





data to its parent process via the intertask communications mechanism. 
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Several facilities directly related to [ob management must be provided by the 
operating system. 

Interjob communication must be provided for. The use of global variables through 
the job control language seems the proper mechanism. That is, there will be a 
class of variables which are global to the entire system or to a set of {obs in addition to 
variables which are local to all tasks of a jobo 

Jobs must be able to initiate other jobs. In effect^ this maor.s that c job must 
be able to present a Logon and a Job Control Language file to the cperatin.g s/cfem. 

There must be facilities for "deadline^* scheduling of jobs. That is, the system 
must be able to initicre a job by a certain specified time and/or guarantee completion 
of a job by a certain specified time. 

Preallocation of resources will be allowed. An installation may require that 
all resources be preal located to all jobs. 

Job sequencing, both basic ordering and conditional execution must be supported. 
Sequencing con be accomplished with the "jobs initiate jobs" mechamsm« This can 
also help v/Ilh sequential resource alloccrion in a required preolioco! v;^n envir':;: ^r;r. 

The facility to terminate jobs cs jobs (that is, oil rcsks relaiir:a \o o ]eb) : ;'j:;t 
be provided. 

One area affected by operational environment and installation is the accounting. 
The accounting implementation wlil have to be parameterized in such a way that 
selected portions can be turned on/off. 
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Considerations of Scale - Differing requirements on job management over the possible 
configurations. 

The requirements of fob management are essentially constant over both 
dimensions of scale and operating environment (small, overlap, large | batch, 
interactive, transaction). 

Conclu sion 

The job management facilities previously planned and required by CDC and 
NCR are basically Identical . V/e see no reason why a common set of facilities 
could not span the entire range of the joint product line. 
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MEMORY MANAGEMENT 
In order to discuss memory management, it is necessary to make some 
assumptions about the type and configurations of memory possible on a reasonable 
system • Given the four elements. Cyber 80 processor, 6150 processing element. 
Cyber 80 memory, and 6150 MSU, a large number of configurations, some with highly 
different characteristics, can be postulated. Unless hordv/cre can make memory 
transparent, the operating system will have to management it. Thus, memciy is 
a resource and v/ill be managed' by kind and access altribute. 

A logical configuration has been specified Info which most "reasonable" 
configurations can be mapped. Only those actual configurations v/hich can be mapped 
to the logical configuration are considered further. Other possible configurations 
are not considered part of the common prcNduct line by the operating system. 

The logical configuration was evolved through two iterations. The earlier 
configurations may be of some interest as rationale for the ultimate logical configuration. 
This first configuration is shown in the diagram below: 
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The ma|or construcfs in this configurafion are that there is one memory which is directly 
accessible by all processors, both central and peripheral . Also, each processor may optionally 
have memory private to it. Memory management then has two or possibly three aspects, 
shared* memory management and private memory management, which can be further 
divided intoCrP. private memory management and peripheral private memory manccjement. 

The odvantages of private memory seem to cc-nrer around rv.ihjcing conn^r-s In 
shared memory. The advantages of shared memory are to reduce djr: rDoundonc/,, 
lower total memory requirements, etc. The task group has only considered private 
memory as it reiafes to thx$ peripheral processors. -Privcite memory usoge on a central prccesscr 
would be very dependent upon the type of msm.ory used; cost, speed, size, etc. 

There are three distinct alternatives to tfe amount of private memory a 
processor could have: 

L None - at least logically which leaves open the option for a hardware 
cache. 

2. Small - which implies mono--tasking in private memory v/ith a single 
operating system task at a time with ro!! out or porlsci! roil out b^ctwoen 

■ toskso''" 

3. Larger -^ which implies that the operotJng system rnulH-tcsks tire private 
memory. 



*Shared memory is often called main memory in other confexts by the task force. 



OPERATING SYSTEM TASK FORCE 



37 



Since there are some dcfinife cost/performance tradeoffs concerning private 
versus shared memory. It is desirable* to expand the previous logical configuration 
to include the one shown below: 
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* 1 • Locally Public Memory and shared memory maybe a logical partliion of physical 
shared mernop/. 

2, The opcral-jny system fask group believes ihat pliyslcai co^'^fi;. . :ci ton:: c; oiogous fo ihis 
logical configuration are deriircible buf quesrions c? cc.- :• • r; .: .rri^inc- ; derive ro vlie 
physical configurations must be answered by Ihe S)'ste:.; ' >;:!;:;;^ Groi-p. 

3. See ^'Memory Mcnauervienr and Tcsk Structures'^ on rjv^xr o^^c. 

This conflguraiion introduces ihe concept of "locally public memory", that is, 
memory that is shared by some, but liol- necessarily al! processcrs. This construct gives 
the greatest degree of flexibility in configuring for cost effectiveness, since only those 
processors which need to access data or execute code in the Locally Public Memory 
access it and yet they can share a single copy of that code or data. 
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Memory Management and Task Sfrucfure 

It is high!/ desirable for a given task to be able to migrate between processors 
in a mull-iprocessor conffgurafion. This diiows desiroble flexibilify in load baloncing. 
Large private memories tend to complicate this v/hile optimizing accesses to main 
(shared) memory. To permii' this task migration the following rule is offered: 

Rule V/hen a processor reaches the point ct which it can no longer perform 
useful v/ork on a task, it^must place the dynamic context of thot task 
In the shared memory where "another" processor may pick up that 
task when it is ready for servicing: 

Private and Locally Public Memory Management 

For private and locally public memory management strategy there are three 
points in a spectrum which roughly correspond to the amount of private memory; none,, 
small, large: , 

1/ Tasks are unawore of the location (re: sliared or privcio memory) of 
dynamic context. 

This may utilize a cache memory approach. 
2. Tasks believe that all dynamic context is in shared mernor/. 

This corresponds to the 6000 system where an entire task is swapped . 
into private memory. 
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3. Tasks decide which parts of dynamic context are In shared and which 
in private memory. 

This approach would probably be used to multiprogram a peripheral 
processor. 

Shared Memory Ma nagement 

It v/as agreed that the dealiocatlon of a page and the allocation cf a 
page when pages are available in shared memory v/ou!d best be dcrio by the 
processor requiring the function. This means that that parr of shared memory^ manage- 
ment would have to be duplicated to run In any processor. Also, this, like other 
facilities, implies some interlock mechanism which can be used betv/een processors of 
different types. . 
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Virtual Memory 

Along with the hierarchies of shared, locally public, and private memory, 
virtual memory has a major effect on memory management. One of the assumptions 
of the operating system task force was that "user memory can be managed by the operating 
system with a consistant virtual memory scheme for cl! CPU's." The system design task 
force has provided the further assumption that virtual memory ccpabllltles are riot 
optional, but will be present, at least to the Cyber SO memory* 

Since the operating system v/iil reside primarily in the peripheral processors, the 
peripheral processors must be able to access virtual shared memory in away conr.Isrant 
With the CPU's. 
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In the preceding diagrarn, the points marked wiih a "a "are v/hore consistent 
virtual memory accesses to shared memory are required. There are several alternatives 
to providing this access from I ho peripheral processor: 

a) peripheral processor software 

b) peripheral processor firmware 
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c) peripheral processor hardware 

d) the cenfral processor upon demand 
or some combination thereof. 

A large part of the operating system should, and for a system of the expected 
magnitude probably must, be basically user tasks, in fact, only that part of the 
-operoling system v/hich CDC has coiled EXEC or NCR has called KERNEL or NUCLEUS 
v/ill not "took" like a user tasks. It is desirable to allow operating system tasks 
to have all of the advantages and receive ail tho prot'^/cticn of user tasks. Virtual 
memory is certainly one of these advanrageso Since rhe operating sysrom v^Iii be 
executing pi irnarily in the peripheral processor and oddressing to a large degree peripheral 
processor memory, some virtual memory scheme is necessary in addressing peripheral 
processor memory. The diagram be lov/ shows the vfrtualmemory accesses required: 
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It was generally agreed by the operating system task force that any code 
written (independent of the language in which it is written) for a virtual memory 
system should and will be different from the same program written for a non-virtual 
memory system. This implies that if virtual memory is not available on the peripheral 
processor, then programs will have to be rewritten (not just recompiled) if the 
decision that it functions on the PP or C? changes. 

To allov/ reasonable migration of tasks between CP and PP, the PP virtuai 
memory mechanism must be^ if not idenfical, a proper subset of the CP mechanism. 
The paging mechanism v/i!i run in both CP and PP units. The ocquiring and reieasing 
of pages when there ore pages availcblo will run. from the processor requirlr^g rlio 
function while page sv/apping will prcbcbly best be serviced by the peripheral 
processor. The key to a good paging mechanism is a good method of working set 
management. This could be accomplished by: 

1. User aids (Pascal compiler, etc.) 

2. Segment usage (entering/exiting) 

3. Hardware aids (pace modification) 



Structure of the OperaHng Sysic 



m 



© All dynamic context of the task will reside in shared memory. 

o All task control tables will reside in shared memory. 

o Shared memory will be addressed virtually by a process. 

o Multiple address spaces in shared memory will be on a segment basis. 

© Segments in shared memory will be paged. 

® Protection in shared memory of a process will be on a segment basis. 
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• The smallest unit of sharing by a process will be on a segment basis. 
e Large portions of the operating system will operate under virtual memory. 
o Processes must be able to dynamically allocate/deallocate segments. 
o While a process is in execution, a method of locking pages/segments 
must be available. 

Scale and ODerci-ina Environnvent 



The major impact of scale on memory managemenr comes of the point of 
inclusl.on or non-inclusion of the Cyber 80 memcr/ In the system. Son'ie port of 
memory managsmsnt is going to be concerned only v/ith that memory. U v/Ili have 
to be designed in such a v/ay that \i can be conveniently Included or not in the system. 

The addition of private memory on central processors will also have some 
impact on memory management. This impact will be dependent upon the type of 
memories added. 

Differing operating environments will necessitate differing scheduling and 
ollocation mechanisms as described In that section of this paper. 
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BLOCK I/O 
Block I/O will provide the device dependent interface between record I/O 
and device \/0. Block I/O functions include managing I/O buffer space, scheduling 
l/O requests to the appropriate device driver waiting for I/O request completion and 
Informing the requestor of the outcome of the requesto Locjical error recovery will ba 
performed by block i/0« 

Block I/O must be structured such that they can be adapted to the operational 
enrivonment: 

!• Over the- spectrum cF memory configurations, one memory management 
technique most probably will not lend Itseif to optimizing memory for all 
increments of the spectrum. Hence, the structure of block l/O must be 
adaptable enough to include the appropriate memory management techniques. 
2.* Likewise, the required device optimization varies with operational 
environment and the structure must accommodate these variances. 
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RECORD I/O 
Record I/O will provide fhe user with access to files at the logical- record 
level. Record I/O groups records into blocks and interfaces with block I/O to read 
or write fhe dafa. Record I/O is device independent except for a set of device 

dependenf rules which defermine the conditions under vyhich block l/O should be 
interfaced. Record compression/ decompression and coliecring is provided by record 
I/O and is transparent to users accessing a file cl- the record I/O leveL Automatic 
buffering of data blocks may be provided where applicable (sequential files). The 
virtual memory system may impoct buffering of data blocks such that buffering may be 
improctical (excessive binding of pages or actually re-reading a buffered block). 
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DEVICE DRIVERS 
A device driver will perform the funcfion of device I/O. A"'device driver ... 
is a task with no differences from any other task other than some defined privileges. 
These privileges would include access to a device and use of l/O instructions. Further, 
a device driver is aware of only one request at o time; it perfornis the physlco! j/O 
transfer, and is specific to a device type or class. The device driver will inform lis 
requestor or caller the outcome (hardware status or formatted status) of the l/O requcir/ 
A device driver will perform hardware error recovery. 

A device driver as on entity v/ill exist as one procedure for each device type 
or class. There is to be one unique context for each j/O request. There Is to be at most 
one active I/O task (device driver) active for each data path. 

A device driver interface with its caller will be via shared address space^. 
The shared address space will include the data area, request information (address, count, 
etc) and outcome information. All pages of the shared address space to/from which I/O 
is being done musf be bound for the duralion of the I/O. 

A device driver should be structured in such a v/oy tnol only the portio^i 
necessary to peiform I/O is resident in a I imited mGiT'.ory sy-.f:..:*. Those pcsrrs wi- -::iv 
are exception conditions or requests (error recovery procedures, etc.) would be fK^n- 
resident. This structure must be adaptable to the degree that portions can be included/ 
excluded across the spectrum orrnemoiy configurations. The cdaptabillty ospect implies 
o design and programming discipline which must be followed at implementation time. A 
device driver, so structured, should be able to span the range of a common operating system. 
The above does not contradict our conclusion that only one version of a specific device driver 
is necessary for all of our logical configurations and variations of operating • 
environments. Device drivers may be the only module with this characteristic. 
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SCHEDULING AND ALLOCATION 

Scheduling and Allocation are related topics having to do with the assignment 
of resource to a task. In particular, we consider scheduling to be making guesses about 
the order in which allocation is to be performed. Allocation involves actually attaching 
resource to a tcisk. 

There mus^ be some interconnection among the various allocators In order to best 

use the resources of the system. In order to accomplish j-his o $:ng!e scnedvi 'rig lis' /t 
proposed. This is a list of j-asks In the system in the order In ' hlcii they aro ^-Kpec: rd ic 
be serviced by a piocessor. Processor servicing is used because^ aprocessor rr^/jst be 
allocated \o o ^ask before any use of a K^source or deollocal-ion cc:n biV pt;rformod. All 
resource allocators should use this list to help them decide how to ollocal-e resources 
among competing tasks. This permits coordinated allocation of resources since the status 
of tasks with regard to resource allocations is summarized in the list. For example, if 
memory is a critical resource In the system then allocation should In general be to the 
task using the most memory. 

A sample list might consist of three parrs: 

1. Expeulted tasks - these tasks v/MI be a!iGcated a processor in Hieir 
current order « no re-ordering v/ili be done. 

2. Assigned (Ready) tasks -these tasks can use a processor but their order 
may be changed. 

3. Unassigned (Not Ready.) tasks - these tasks cannot presently use a 
processor. 
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Beyond these three parts the list Is ordered by other criteria including, but not 
limited to, possession of critical resources, time in system (aging) and externally supplied 
priorities. The nature and effect of these criteria is certain to change from installation to 
installation. It is therefore necessary for both NCR and CDC to provide for variation 
of scheduling algorithnis. A single scheduling facility to man! pu I al-e the above list unclc-r 
control of an externally provided algorithm must be provJdad by both comnanloSo 

Such a scheduling facility could be table driven where the scheduMifg cl^rori^hin 
is established as entries in a table and the scheduler Is a procedure or set of r^'occdbTes 
which manipulate tasks according to these entrieSo The possible ta5;!< stales are reprasenred 
as rows of a rnatrlx. The columns of the matrix contain pcrarnerers used for ordering the 
tasks in each state and information about moving tasks from that state to another. Tasks 
fit one of the states at creation and are moved from state to state according to the 
matrix as events occur. 

The intent of the allocation and scheduling algorithms differs in the different 
operational environments. In Interactive systems, the Important objective is \:^\jo\\y 
response time, in botch system;total throughput is mc:;t important. Viansac-iv:. sysioms 
usually ottarnpi to maximize throughput without cau::In3 any rciponss timo to ev-xeed 
some maximum. These objectives are achieved almost totaily through the scficduilng 
and allocation algorithms used. The combination of one or more operational 
environments is also heavily dependent upon a good scheduling ond allocation olgoriir.m. 

Since the algorithms are based on operational environment, both NCR and CDC 
need to provide standard algorithms or tables for use or modification by their 
customers. In many cases, a single algorithm (table) will apply to both NCR and CDC 
customers. . 
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More sophisflcafed scheduling algorithms require more space since the scheduling 
matrix requires more rows (sfafes) and more parameters per roWo The use of such a matrix 
is likely to consume more processor power. On smaller systems, it may not be cost- 
effective to use very sophisticated scheduling algorithms. This means that scheduling 
algorithms provided for the top of the line may not be ussfu! of the bottom. Also, the 
scheduling algorithms provided for tha bottom of the line may not bo able to got opfirrtunr 
performance out of the top of the llneo 

The only mojordifForence of scale In resource allocaticii h \i\ the number oF 
resources. It Is possible that the additional resources In a laroo sysi rnv would complicate 
the scheduling and aliocatlon algorithms (In particular the processor scheduling algorithm 
since it must handle all interdependencles). Additional complexity is more likely due 
to the number of types of resources, not the number of resources alone. In the range of 
scales being considered the number of types of resources is likely to be fairly constant. 

Frequent allocation and de-allocation of resources occurs in interactive systems. 
This contrasts to batch systems v^here resources are usually allocatod on a job- Ly- L^b 
basis. Transaction systems are usually buiit ro run with pre-cllococu resources •'x.>-;- 
for processors). This allocarlon Is changed only In case of error or c'hor extraorv;^; ' 
conditions. The less frequently allocation is performed rho less sensil-ive the systerr; 
to improper design of the algorithms. This means that sophisticated allocation algor , 

sensitive to details of the environment are required jn Interactive systems but snjip!;^? 
algorithms are adequate for batch. Transaction systems require a sophisticated processor 
scheduler only. 
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JOB CONTROL LAN GUAGE PROCESSOR 



The Job Cor^frol Longuage (JCL) is the language used to communicate with the 
system and direct it to do work. The JCL processor Is the system routine that interprets 
and processes the JCL statementSo 

The system or job control langucge has many faces, end may, by sojt^c definlH^ 
be a number of languages. It Is the Ianguage(s) used by operarovs and users to cornmunj c-^te 
With the system and direct its operationo The Icnguageis) must suppori;: remove/main 
console operators, remote terminal operators, remote/local boichu-:: is, and inleractlve 

■users. ' ■ , 

The confusion as to how many languages there ore arises from recognition of the 
overlapping requirements among users. For example, all users will want to manipulate 
|ob and file parameters, both the console operator and interactive users will wont to 
function in an interactive mode, etCa 

The copabijifies and general approach developed by CDC^^ CaiiorJian Dovcloprnoni 
Division, (CDD), and described in their Commond Loncuoge Descrip! ion :!ocL/:rier t raH:^'; ; • 
the needs of NCR and CDC across the range of the product line op.d In rh,e f!:re:v rfiaja* 
operating environments; i,e,, batch, interactive and transaction. The following are 
some of the characteristics and features: 

--The JCL is terminal oriented which subsets effectively for all operational 
environments. 
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—-The JCL should be natural and not require programming experience to ube It 

effectively. 
— The user is not restricted to rigid formats. 
— The JCL must provide the capability to be redefined at the user level and 

allow the user to define his own commands; i.e., it must be extensible. 
— Inter-Job communication will be provided through the JCL using global 

variables. 
— Jobs may initiate other jobs. Thjs allov/s job sequencing. 
' — Speciol features and facilities mpy be provided io privileged users; e.g., 

operators and operations managers. 
— The JCL should provide 'help' to the user. 

--The JCL Processor must provide two modes of operation. One provides for 
immediate Interpretation and processing of JCL statements. The other allows 
forcollecting JCL statements without interpretation. 

The risks In a common JCL processor are minimal. /vAuch' of the work has already 
been done by CDD in defining the longuage arid the processor. 
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DEVICE ALLOCATION 

Device Allocafion can fake place at any time when a task decides it requires 
the use of a device. In some cases (at Installation option) all allocation will take place 
at the sfart of a Job. 

Usually devices are allocated to system tasks which v/i II operate the devices 
as requested by several userSo It is also possible (at instalicticn option) for devices to 
be allocated directly to users. This option v/ill be used mainiy in bcrci) systems. Such 
qliocation is usually discouraged in interactive systems end not pre .Jded in transaction 
systems. .Smaller system,s also discourage allocation of devices ro vz^rs becou^a of ihe 
smaller number ot total devices available. 

Allocation of a removable volume device (e.g., disc, magnetic tape ) implies 
the mounting of fhe proper volume on that device. In some cases, allocation may 
depend upon where the operator mounts the volume. Allocation of devices to users implies 
the existence of private volumes for mounting on those devices. 

Communications devices are treated exactly as are other devices in that they are 
normally allocatsd j-o system tasks (a. g,, Trcnscction Distributor) bul- cof) b:: olioccr^n jo 
users, if necessary. Dial-up terminals ore treated cs removabio volume^ /i;i rhe- c-.;:r'inHy 
dialed in terminal being^'mounted." 

One algorithm for I/O device allocation is not suffl: ' for all syslems over 
the range and all operational environmenfs. Multiple routii. /nay have to be piovided 
to satisfy various users. 
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BINDING 

Binding is done at times defined by operations performed on the program such as 
compiling, linking (entirely a binding function), loading, and execution (dynamic 
binding). The loj-er binding times provide more flexibility in operating environment 
at the expense of redundant and v/asteful binding operations. Very dynamic systems 
such as most interactive sysfems require later binding times then constant systems such 
as commercial batch systems. Transaction systems usually inv::. ..; i-^equer;r b\}\ wen- 
controlled bindings. Scientific batch systems do not usually rec: ' o lore bincir-ig times 
but their changing nature usually means that the overhead Involved in Idrerbjnding is not 
hormfulo In order to reduce overhead costs, operating systems code should be dynamically 
bound only when necessary. Virtual Storage systems usually provide facilities to aid 
dynamic binding but improper use of these facilities can cause severe performance 
degradation. There is no reason why systems cannot be built to both avoid the severe 
degradation associated with dynamic binding and provide facilities for earlier binding 
when desired,. 
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Stafic Binding 
How you can fell 

- It's normdlly a one fime affair between the operating system and the process. 

- The operating system normally links all external references of a process prior 
to execution. 

- Depending on fhe versatility of the operating system pre-a! location and 
and binding of real memory may be somev/hct dynamic. 

- Both CPU and PPU could partake in the affair. 

- Linear space requirements are normally known .prior to ex-jcutlon. 
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Dynamic Binding 
How you can fell 

- Ifs an affair wifh the operating system that can go on for the life of the process^ 

- Operating system links and loads only that procedure that was externally referenced, 
. - The external references of the procedure called will not be resolved, 

- There Is normally no real memory pre-allocated to the proccd^jre of a process. 

- Both the CPU and PPU could porrake in the affair. 

Control Data views dynamic linking end loading as an inrog-al part of live 
Virtual Memory mechanism (at least cs of 4/10/73), It is assumed r:-::! the operating 
system will use dynamic leading and Unking in a large portion of its processors. NCR and 
CDC*s use of dynamic loading and linking is questionable for first release for the 
operating system* 
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OPERATOR CONTROL 

Operator Control is that parf of the system fhaf provides the computer operafor 
with informotion about the status of the system and the jobs being processed, and the 
ability to influence or control the behavior of the system within certain limits. 

Operator Control is required by all systems over the range. The systems cannot 
operate without operator action.. Operator action should be directed prinv.:!;:': y v/ fha 
system. Operator communication and control occurs through um; of the JCL ' . '^.e 
"operoior may have special facilities and features provided for pfiviieged ls^^c\■^. A common 
Operotor Control facility can be provided by including parameters ihot can be se\ by 
installation opfion. 

Both CDC and NCR believe that the operator communicates v;Ith the system 
through ihe Job Control Language. . 

A common Operator Control facility can be provided with minimal risk. Since 
the facilities provided In this area are through JCL, there ore few, if any, problems and 
issues that need resolution outside of the JCL area. ,, 
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DATA MANAGEMENT 
The "operafing system" will to the best of our knowledge provide to the data 
management system all interfaces, task/process interfaces and procedure Interfaces^ 
which are available in the system thus fulfilling the requirements (requests) of data 
management. 
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APPENDIX A - DEFINITIONS 

ALLOCATION - The act of picking a request for a resource and honoring that request. 

DEVICE DRIVER - An operating system task which performs a physical I/O transfer 

from a specific device. 

DEVICE HANDLER ~ The portion of a device driver which is not sensitive to scheduling 

criteria. 

DEVICE TYPE - A class of devices which are similar enough in operation thai fhey can 

be handled by a single device driver procedure. 

DYNAMIC CONTEXT - The data for a process which is changed during execution. 

EVENT — Anything which causes a list of requests for service to be altered. 

EXEC - The non-task procedures necessary for managing the interaction between 

processes, the state chcnges of a process, the creallc: cF 
processes and inactive tasks, and the selection of 0:0:::; CiS 
for a processor. 

JOS - The irnnicdlcie user of o compuling system's view or a piece of work. From 

the operoting sysfem it is a rather arbitrary set of f asks that 
ore performed as a result of information between a users 
LOGON and LOGOFF statements. 
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JOB CONTROL LANGUAGE - The language used by an operator or other immediate 

user of a computing system to request services and direct the 
operaljion of the system. 

MEMORY, LOCALLY PUBLIC - Memory accessible by multiple, but not necessarily all, 

physical processors in a computing system. 

ME/vAORY, PRIVATE - A'\emory accessible by only one physical processor. 

MEMORY, SHARED - Memory accessible by all physical processors !n a cornpunng 

system. 

PROCESS - An active instance of a task. A process is the only entity applied to a 

-processor by .EXEC .to,getwork.done. 
A process normally consists of: 
1 • A dynamic context unique to this process, and 
2. A set of procedures shared with other processes that have 

been created from the scrne inactive task • 
A process has its own addre>s space which in ay have ':^:.'ialn 
segments shared v/ith other processes. 

REA.DY STATE - The state of a process which is oble to use a processor as soon as it 

con be allocated* 

SCHEDULING - The act of ordering lists of requests for service at the time requests 

are made . 
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TASK - 1 . The smallest unit of work recognized by the sysfem . 

2* The object in the system to which resources are allocated. 

These two definitions are not contradictory . Either one can be 
used as the primary definition and the others will follow, 

TRANSACTION DISTRIBUTOR - A service function for transaction systems. It 

inputs transactions from files and distributes them to the 
appropriate processing tasks. The entire uporctlonlfi 
controlled through a transaction distribution Icnguage . 

WAIT STATE - The state of a process which cannot use a processor until some event 

occurs. 
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The following pages show the object size of SCOPE B-M modules 
grouped somewhat by function- All numbers are octal bD-bit 
words- The "Proc" column identifies the processor -CP or C> 
used by the module- 
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13m 




P 
C 
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' CPMTR 
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SE37 
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52 
SS 

52 
77 

571 
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P 
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P 

.P 
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Psrmancnt File ManaciQf 
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IDL 
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c 


PFCCP 
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P 


PFC 


b77 


P 


IPF 
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p 


PFA 
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p 


2FA 


1302 


p 
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1005 :.. 


p 


PFP 


1270 


p 


PFE 


130y 


p 


PFR 


M71 


p 


IPD 


M22 


p 


EPF 


732 


p 


PFS 


35 


p 


PRn 



Descr i otion 



System monitor 
System monitor 
ECS Driver 

Terminate deadstart 



Dynamic system display 

LODO resident overlay 

Ifi DSD console command overlays 

Ifl DSD display driver overlays 

7D0D station routine 

17 70DD station routines 

Overlay loader and dayfile message 

processor for DSD 

Device queue .nanacor 

Display qood -^crn--- : - 
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Permanent file catalog 

.Permanent file queue manager 
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Permanent file attach 

Utility I/L processor PFA segment 

Load permanent files 

Permanent file purge 

Permanent file extend 

Permanent file rename 

PFA Delay Overlay 

Send permanent file audit information 

Position function storage al location 

Permission code processor for perk 
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Size 



Proc 



Name 



Description 



Permanent File Utilities 



EM33b 


c 


17537 


c 


llSbb 


c 


51DM2 


c 


S003 . 


c 


IDbL 


p 


lOSl 


■p 
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p 


IDOl 


p 


ML-iS 


p 


IDTSQa subtoi 
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AUDIT Audit permanent files 

PFDUnP Dump PFD and RBTC 

DUflPF Dump permanent files to tape 

LOADPF Load permanent files 

TRANSPF Transfer permanent files 

DPF . Dump permanGHt files 

TPF Transfer p2rrnan£:ent files 

IDU DUMPF initialization 

TPT Transfer permanent file tables 

PFD Permanent file dump 

MASS STORAGE I/O 



Allbcatable Devices 
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, ,C ^ 
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MbO 


P 


31)0 
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h 


P 
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P 
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Release record block chain 
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P 


MES 
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P 
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Stack processor main program 
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P 
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Driver overlay for tib03-I 
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P 


3Sfl 


Driver overlay for bb3a 


12M 


P 


3ST 


Driver overlay for btiDS-II 
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P 
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Driver overlay for fibS 
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3SU 


Driver overlay for am 
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Driver overlay for SEl 
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P 


3SU 


Driver overlay for flMl 


i£l^U- 


P 


3SS 
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SEP 
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p 
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p 


BET 
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3ER 


ECS Ih-^ivar overlay for fib£i 
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p 


3EU 
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• 3Zhi 
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p 


3ES 
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P 


ISX 


Process stack processor errors 
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P 


CEM 


Central error manager 


3p.i- 


P 


7EC 


Generate ECS buffers 
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Size 



Proc 



Name 



illocatable 


Devices 




lt.7 


P 


SDA 


MD5 


P 


IPK 


502 


P 


3PK 


IDIS 


P 


IDA 


2hH 


P 


EKG 



Description 



Family disk pack label processor 
Sequential pack close 
Sequential pack initialization 
Disk pack label routine 
Family pack end of job processor 



Tape Labels 



3L31 



C 
P 



LABEL 



IM Overlays 
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UNIT RECORD I/O DRIVERS 
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IIR 


p 


US 


p 


EIS 


p 


11(2 


p 


IIU 


p 


2LP . 


p 


5FC 


p 
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p 


IPL 



Size Proc- Name 



lDt,7 
llbD 
lObl 

S21 

121 

.343 

2S7 

3b3 

11 

TAPE SCHEDULING 



223 P VSN 

302 P ITS 

172 P 2TA 

TAPE DRIVERS 

M27 P iriF 

127S P IMT 

SM2 P IRT 

SMD P IRS 

SbS P INR 

SDO P Ih^ 

tDt, P lliJi 

Mil P ITF 

522 P IWS 

MDt, P im 

1,32 P ETB 

SD7 P IR^l 

2S7 p bwn 

ISS P 7'Jl 

3H P . 7li!2 

1D3SM P 

52 p bin 

223 P LLC 

101 P 7T1 

ipi P 7T2 

31D P flT3 



Description 

JANUS Main Program 

JANUS Main Program 

JANUS Routine 

Initiate JANUS Control Point 

JANUS Backspace Print Name 

On-Line Printer Driver 

On-Line Card Punch driver 

On-Linti Card Reader LT-iver 

Plotter ProQrrui) -CDunif-v, } 



Visual Serial Number 

Tape Sampler 

Tape Assignment Overlv-jy 



Multifile Position Routine 

for ANSI Labelled Tapes 
Driver for Long Record Stranger -CLj- 

Tapes for 7-Track Tapes 
SCOPE Tape Read Driver 
Stranger -CSl Taps Read Driver 

for 7-Track Tapes 
H-Track S-Format Tape Read Driver 
T-Track SCOPE Format Tape Write 

Driver 



SCOPE Tape bh-itG Driv 


er for . 


7-Track Tap<:^": 




Forward Skip Koutin>;:^ 


yor Tac-:: 


Strarigt2r -[S> T.vOG cirvi 


■ e /DrivL';-- 
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T'-Track ::C\j\''Z rcrmac 


lapG '■ :'^-.:dd 


Drivt^r 




I/ayf'ilvr iiGssagc^s f,o-r , 


1/0 Ruqu<2 


Overlay to SWK 




Overlay to SWrl 




n RBcovary overlays 





.v'zir 



Load Field Name (lessagss 

Load Conversion Table into fHITC 

ANSI/DISPLAY code conversion 

Table for tlllTC Memory 
EBCOIC/Display Code Conversion 

Table for MflTC Memory 
Segment for Loading of MMTC 

Conversion Memory 



OPERATING SYSTEM TASK FORCE 



B-5 



JOB PROCESSING 
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P 
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P 
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P 
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P 
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P 
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P 
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P 
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3dy 
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c 
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c 


10 
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c 


SYS.RM 
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c 


FIbE 
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130DD 
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c 
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Description 

Control Card Reader 

Advance Jobs 

End of Job Processor 

Translate Job Card 

Initiate a Batch Job 

Swapin or Rollin a Job 

Overlay to Process P<3pitv Error 

for ISI 
Swapout or Rollout a Job 

Integrated Scriaduler 



Circular Input/Output 
Add Message to Dayfila 



Sequential records 
Uord addressable 
Indexed sequential 
SAC 
fi-bit 
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CHECKPOINT/RESTART 
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C 

c 
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DUMP/RESTORE I/O QUEUES 
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CHEKPT 
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CKP ' 

CYl 

RST 

IRC 



Description 



Tape Checkpoint 

Reset FNT for Restart 

Restore Control Point Area for 

Restart 
Reload Core for Restart 
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C 


XXXRES(3 




SOD 


C 
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p 
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Restore C^uaus 
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p 


XTjQ 


Dump duaus 



niSCELLAfJEOUS 



12LL 


c 


TRAP 


3bl3 


c 


TRAPPER 
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c 


SETCORE 
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p 
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p 


MEM 


3m 


p 


ILT 


317 


p 


IDF 


mo 


p 
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p 


ITD 


1332D 


c 


DNFECS 
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p 


RPV 
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p 


STS 


lObti 


p 


DFiP 



tQa^d'O^ctal Corrections 
Process flemory Function 
Load Jobs from Tape 
Dump Dayfile 
Tape/Disk Blank Labels 
Dump Output File to Tape 

Procc?£^s Reprieve Function 
Status Routine 
Dump CH 
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UTILITIES 



LOADER 



Jvize 



ProC' 



Name 



102SS 


c 


SECBILD 


blE 


c 


SE6RES 


bMDO 


c 


LOAD 
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c 


LOADC 


1L3M 


G 


LOADM 


tSbb 


c 


LOADU 


SSO 


c 


LOADUC 


2D7D 


c 


LOAjJUn 


257 


c 


UOLOAD 


bS 


c 


LIBRARY 


2SS1 . 


c 


LOADO 


mas 


c 


LOAI'Ql 


SEE 


c 


L0ADD2 


1237 


c 


LOAD 03 


3Dt, 


p 


LDL 


3i|S 


p 


LDV 


1031 


p 


LDQl 


EDIT LIB 






M07M 


c 


EDITLIB 


im3D 


c 


EDITS YS 


S723 


c 


EDITUSR 


bis 


p 


tIDI 


2 


p 


LfID 


bl 


p 


SRB 


UPI>ATE 






133L2 


c 


UPMTE' 
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S3 




TRANS R 


; : 17 




TRANS F 



Description 



Loadar Utility 
Absolute Overlay Loader 
Absolute Overlay Loader 



... I 

Move System Directory -CEDITLIB useJ 

Dummy EDITLIB Overlay ' 

EDITLIB Routine to Ccrnrdet^ 

Disk Address of Rv'::ord 



11 



u:3 



JOB 



Proceijs Job Dependency 
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FILE UTILITIES 

Size Proc ' Name 

111 C BKSP 

b32S C COMPARE 

ISb C COPY 

LD3 C COPYBF 

tDM C COPYCF 

t.03 C COPYCR 

bOS C COPYBR 

S32Q C COPYN 

SIS C . COPYSBr 

333? C COPYL 

2MMM C COPYECD 

217S C COPYXS 
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File Close Routine 

Close Tape File 

Tape Open Routine 
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p 
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p 
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p 
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p 
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2M 


p 
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p 
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p 
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p 
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p 
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p 
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p 
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p 
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537 
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Description 



Check if INTERCOM control point 
Connect file name to TTY 
Multiplexor driver 
Multiplexor driver 
Multiplexor driver 
High speed EXFC". T proces^nr 
Process special air^ictiv;:^: 
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Graphics input /output processor 
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Assign new user table 
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P 
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P 
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P 
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P 
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P 
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P 
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P 


IPT 
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P 
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P 
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P 
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L7 


P 
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P 
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P 
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P 


TBL 
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P 
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2m 


P 
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P 
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P 
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P 


3f1E 
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P 
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P 
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P 
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Input file transrissi 
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ansmitter 
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SCIENTIFIC 




. 75x5': 00 


3.5x145 


145 MP 


3 


6150X 


0.25-2 MB 


16 MB 


1-2 


10-30 


oo 


& BUSINESS 


* 25 


.5x6600 


2,5x145 


145 


2 


6150X 


0.25-2 MB 


16 MB 


0,1 


0-15 . 


-< 


(PI) 


15 


.2x5500 


1.5x1-15 


small 145 


1 


6150X 


0.25-2 MB 


16MB 


0-1 


0-15 


m 


MEDILl-.! 


45 


_. 


1k15S 


158 


. ■ 3 


6150 5Cr.s 


0.5-4 .MB 


30 1vlB . 


1-3 


10-40 


^ 


BU3n:ES£ 


SO 


<.» 


2.:-.vl45 


145 MP 


2 


6150 50ns 


0.26-2 MB 


16 MB 


1-2 . 


• 10-30 


^ 


(PO) 


* 15 


— 


1.5x145 


3^5 


1 


., 6150 50ns 


0.25-2 MB 


16 MB 


0-1 


0-15 


o 


.SJvlALL 


15 


— 


1.5x135 


135 


2 


6150 90ns 


0.25-1 MB 


.16MB 





M«> 




BUSIls^ESS 


* 10 


_.. 


1.5x125 


125 


1 


6150 90ns 


0.25-.6 M3 


■ 16 MB 





■-.-, 


m 


CP) 


5 


— . 


1.5x115 


115 


. 1 


615C OCns 


o.;:-.i. .;!5 me 


16MB 





— 





♦Target Cor^\:^..:'-d' u 
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:l \i: yet to be deiLned and per: cms C. 3 x. 6'Xj in ScientLflc CPU performance. 
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APPENDIX D -. DISTRIBUTION OF O.S. MODULES 



The 0,S, Task Group generated the list of functional elements in the following table 
as characterizing the bulk of an operating system. The members of the group were 
then polled as to where in their best judgement the funci !ons should be performed 
in a system consisting of both FPUs and CPUs using the foilov/Ing definitions. 

PP - The function should only be done in the PP 

CP - The function should only be done in the CP 

Both - The function would be performed in both the CP atid PP 

Either — Determination as to where the function is to be performed is uncertain 

ASSUMPTIONS 



!• Hardware can support any distribution of components required . 
2, The size and number of processors In a configuration will be determined bv ihe 
distribution of 0,S. components rai her if^an vice versa. 
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Votes of the Task Group Members 



PP 



CP BOTH EITHER 



Device Drivers 




9 








Block I/O 




8 






V 


Record I/O 




2 


2 


5 




Data Management 




7 


1 


1 




Loaders -^Static 




8 






1 


- Dynamic 




T 


3 


3 


2 


Tosk MaBagement 








9 




JCL Processor 




7 






2 


Operator Control 




8 




1 




Utilities 




3 




4 


2 


Shared Memory Mgmt . 


- Swap 

- No Swap 


4 




1 
9 


2 


Job Mianagement 




5 




2 


2 


Hardware- Dlcgnosrics 








___9 


...^^ 



!/0 Device A! local Ion 



